So developers need to call this nullify_stdout method manually?

Yes, as lbustelo pointed out in issue #351, custom python function containing prints can use this decorator to wrapper it, so user defined prints won't mess up the tuple emits from the bolts. Like this:

@nullify_stdout
def custom_fun:
    print "this won't come into python process's stdout to mess up emits."

sorry I didn't add an example like this in my PR.

Another way is to assign sys.stdout = NullDevice() globally in the module, while sendMsgToParent() use original_stdout so it can write to stdout normally. But this way I don't know when to reassign sys.stdout back. Any thoughts here? I would like to follow it.

Would it be better if storm.py handles all the silence prints details, so it will be transparent to the developers?

Then I think assigning sys.stdout = NullDevice() globally in the module while only sendMsgToParent() using original_stdout will suffice. What do you think?

About reassigning sys.stdout back, one way I can think of is wrapping all calls to self.process(tuple), self.initialize(stormconf, context) etc with your nullify_stdout.

I gave it some fresh thoughts today, now I think, since all prints will be read by storm's JVM-component, we must forbid any prints outside of sendMsgToParent() function. So, there is no need to reassign sys.stdout back. Does this make sense to you?

Or, alternatively, we can reassign sys.stdout back at the end of run() function, since this should be the last call of custom python script (see splitsentence.py example for reference).